Control of accesses for IMS services

ABSTRACT

A method for operating a UE is provided. The method comprises retrieving, by the UE, an IMS transport policy comprising a set of service transport rules. The set of service transport rules may include an indication of at least one IMS service and an indication of a policy for at least one access technology associated with the at least one IMS service. The indication of the policy may indicate whether the access technology can or cannot be used to transmit data between a network element and the UE when a first IP flow for a first IMS service associated with the UE has at least one IP flow characteristic in common with a second IP flow for a second IMS service associated with the UE, or whether the access technology is preferred over another access technology for transmitting data between the network element and the UE in such circumstances.

BACKGROUND

The IP (Internet Protocol) Multimedia Subsystem (IMS) is a standardizedarchitecture for providing multimedia services and voice-over-IP callsto both mobile and fixed user equipment (UE). The Session InitiationProtocol (SIP) has been standardized and governed primarily by theInternet Engineering Task Force (IETF) as a protocol for setting up andmanaging IMS-based calls. As used herein, the term “UE” can refer tomobile devices such as mobile telephones, personal digital assistants,handheld or laptop computers, and similar devices that havetelecommunications capabilities. Such a UE might comprise a wirelessdevice and its associated Universal Integrated Circuit Card (UICC) thatincludes a Subscriber Identity Module (SIM) application, a UniversalSubscriber Identity Module (USIM) application, or a Removable UserIdentity Module (R-UIM) application or might comprise the device itselfwithout such a card. The term “UE” may also refer to devices that havesimilar capabilities but that are not transportable, such as fixed linetelephones, desktop computers, or set-top boxes. The term “UE” can alsorefer to any hardware or software component that can terminate a SIPsession.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a diagram of a basic UE/network architecture according to anembodiment of the disclosure.

FIG. 2 illustrates IP filter information according to an embodiment ofthe disclosure.

FIG. 3 is a flow diagram showing basic handling in a UE of IMS TransportPolicy according to an embodiment of the disclosure.

FIG. 4 is a diagram of a basic structure of IMS Transport Policyaccording to an embodiment of the disclosure.

FIG. 5 is a diagrammatic representation of IMS Transport Policyaccording to an embodiment of the disclosure.

FIG. 6 is an alternative diagrammatic representation of IMS TransportPolicy according to an embodiment of the disclosure.

FIG. 7 illustrates an example of data encoding on a UICC according to anembodiment of the disclosure.

FIG. 8 illustrates general message flow permutations according toembodiments of the disclosure.

FIG. 9 illustrates examples of network node implementations according toan embodiment of the disclosure.

FIG. 10 illustrates examples of message implementations according to anembodiment of the disclosure.

FIG. 11 illustrates possible LTE implementations of provisioning IMSTransport Policy to a UE according to an embodiment of the disclosure.

FIG. 12 illustrates a possible implementation of provisioning IMSTransport Policy to a UE for GPRS according to an embodiment of thedisclosure.

FIG. 13 is an example of standards text for 3GPP TS 36.300 according toan embodiment of the disclosure.

FIG. 14 is an alternative example of standards text for 3GPP TS 36.300according to an embodiment of the disclosure.

FIG. 15 is a simplified block diagram of an exemplary network elementaccording to one embodiment.

FIG. 16 is a block diagram with an example user equipment capable ofbeing used with the systems and methods in the embodiments describedherein.

FIG. 17 illustrates a processor and related components suitable forimplementing the several embodiments of the present disclosure.

DETAILED DESCRIPTION

It should be understood at the outset that although illustrativeimplementations of one or more embodiments of the present disclosure areprovided below, the disclosed systems and/or methods may be implementedusing any number of techniques, whether currently known or in existence.The disclosure should in no way be limited to the illustrativeimplementations, drawings, and techniques illustrated below, includingthe exemplary designs and implementations illustrated and describedherein, but may be modified within the scope of the appended claimsalong with their full scope of equivalents.

As used throughout the specification, claims, and figures, the acronymsbelow have the following definitions. Unless stated otherwise, all termsare defined by and follow the standards set forth by the ThirdGeneration Partnership Program (3GPP) technical specifications or by theOMA (Open Mobile Alliance).

-   1×RTT 1× (single-carrier) Radio Transmission Technology-   3GPP 3rd Generation Partnership Project-   AAA Authentication, Authorisation and Accounting-   ACK Acknowledge-   ADS Access Domain Selection-   ANDSF Access Network Discovery and Selection Function-   ANQP Access Network Query Protocol-   AP Access Point-   APN Access Point Name-   AS Application Server-   AT ATtention-   BBERF Bearer Binding and Event Reporting Function-   BSC Base Station Controller-   BSSID Basic Service Set Identifier-   BTS Base Transceiver Station-   CDIV Communication Diversion-   CSCF Call/Session Control Function-   DHCP Dynamic Host Configuration Protocol-   DM Device Management-   DNS Domain Name System-   DSL Digital Subscriber Line-   EAP Extensible Authentication Protocol-   EPC Evolved Packet Core-   ePDG Evolved Packet Data Gateway-   EPS Evolved Packet System-   ESSID Extended Service Set Identifier-   E-UTRAN Evolved Universal Terrestrial Access Network-   FQDN Fully Qualified Domain Name-   GERAN GPRS EDGE Radio Access Network-   GGSN Gateway GPRS Support Node-   GPRS General Packet Radio Service-   GRUU Globally Routable User Agent URI-   GSM Global System for Mobile telecommunication-   GTP GPRS Tunnelling Protocol-   H-PCEF Home network PCEF-   H-PCRF Home network PCRF-   HLR Home Location Register-   HPLMN Home PLMN-   HRPD High Rate Packet Data-   HSS Home Subscriber Server-   HTTP Hyper Text Transfer Protocol-   I-CSCF Interrogating Call/Session Control Function-   IANA Internet Assigned Numbers Authority-   IARI IMS Application Reference Identifier-   IARP Inter-APN Routing Policy-   IBCF Interconnection Border Control Function-   ICSI IMS Communication Service Identifier-   IEEE Institute of Electrical and Electronic Engineers-   IEI Information Element Identity-   IETF Internet Engineering Task Force-   IFOM IP Flow Mobility-   IMAP Internet Message Access Protocol-   IMS IP Multimedia (core network) Subsystem-   ISIM IMS SIM-   ISRP Inter-System Routing Policy-   ITU International Telecommunication Union-   LDAP Lightweight Directory Access Protocol-   LED Light Emitting Diode-   LSB Least Significant Bit-   LTE Long Term Evolution-   MAP Mobile Application Part-   MAPCON Multi Access PDN Connectivity-   MCC Mobile Country Code-   MME Mobile Management Entity-   MMTeI Multimedia Telephony-   MNC Mobile Network Code-   MSB Most Significant Bit-   MSC Mobile services Switching Centre-   MSRP Message Session Relay Protocol-   MT Mobile Terminated or Mobile Termination-   NAI Network Access Identifier-   NAS Non-Access Stratum-   NFC Near-Field Communication-   NSAPI Network (Layer) Service Access Point Identifier-   NSWO Non-Seamless Wireless Off-load-   OMA Open Mobile Alliance-   OPI Operator Preference Indicator-   OPIIS Operator Policies for IP Interface Selection-   OS Operating System-   OTA Over the Air-   P-CSCF Proxy Call/Session Control Function-   P-GW/PDN-GW Packet Data Network Gateway-   PCEF Policy and Charging Enforcement Function-   PCRF Policy and Charging Rules Function-   PDG Packet Data Gateway-   PDN Packet Data Network-   PDP Packet Data Protocol-   PDSN Packet Data Serving Network-   PIN Personal Identity Number-   PLMN Public Land Mobile Network-   QoS Quality of Service-   QCI QoS Control Identifier-   R-UIM Removable User Identity Module-   RADIUS Remote Authentication Dial-In User Service-   RAM Random Access Memory-   RAN Radio Access Network-   RAT Radio Access Technology-   RAU Routing Area Update-   RFC Request for Comments-   RFU Reserved for Future Use-   RNC Radio Network Controller-   RRC Radio Resource Control-   RTCP Real-Time Control Protocol-   RTP Real-Time Protocol-   RTT Real-Time Text-   S-CSCF Serving Call/Session Control Function-   S-GW Serving Gateway-   SBC Session Border Controller-   SCTP Stream Control Transmission Protocol-   SDP Service Description Protocol-   SGSN Serving GPRS Support Node-   SIB System Information Block-   SID Service Indication Data-   SIM Subscriber Identity Module-   SIP Session Initiation Protocol-   SMS Short Message Service-   SOAP Simple Object Access Protocol-   SQL Sequence Query Language-   SSID Service Set Identification-   TA Terminal Adaptor-   TAU Tracking Area Update-   TCP Transmission Control Protocol-   TDF Traffic Detection Function-   TE Terminal Entity-   TID Transport Indication Data-   TLV Tag Length Value-   ToS Type of Service-   TS Technical Specification-   UDP User Datagram Protocol-   UE User Equipment-   UICC Universal Integrated Circuit Card-   UMTS Universal Mobile Telephony System-   URI Uniform Resource Identifier-   USB Universal Serial Bus-   USIM UMTS SIM-   USSD Unstructured Supplementary Service Data-   UTRA UMTS Terrestrial Radio Access-   UTRAN UMTS Terrestrial Radio Access Network-   V-PCEF Visited network PCEF-   V-PCRF Visited network PCRF-   ViLTE Video (over IMS) over LTE-   VoLTE Voice (over IMS) over LTE-   VPLMN Visited PLMN-   WLAN Wireless Local Area Network-   XCAP XML Configuration Access Protocol-   XML eXtensible Mark-up Language

As used throughout the specification, claims, and figures, the termsbelow have the following definitions.

-   -   AAA Proxy An entity that forwards AAA protocol signalling        between two or more entities e.g. other AAA Proxies, AAA        Servers, etc. Typical protocols used are RADIUS and Diameter.    -   AAA Server An entity that terminates AAA protocol signalling and        may provide responses to requests. Typical protocols used are        RADIUS and Diameter.    -   Access Point An entity that terminates AAA protocol signalling        and may provide responses to requests. Typical protocols used        are RADIUS and Diameter.    -   Access Technology Examples of access technologies include, but        are not necessarily limited to, mobile/cellular (e.g. 2G/GERAN,        3G/UTRAN, 4G/LTE/E-UTRAN, CDMA, CDMA2000, etc.), Wi-Fi/WLAN        (e.g. IEEE 802.11-based technologies, etc.), Bluetooth, NFC,        WiMAX, Wireless Charging/Chargers, Ethernet, cable modem, DSL,        Fibre, USB, Wireless USB, etc.    -   Control Plane Data Also known as “Signalling plane data”, or        even just “control plane” and “signalling plane”, this includes        all SIP methods/messaging, XCAP request and response messages,        and IMAP messaging.    -   Network Identity A PLMN code (e.g. Mobile Country Code (MCC) and        Mobile Network Code (MNC)), a WLAN identity (e.g.        SSID/ESSID/BSSID), an NAI, etc.    -   User Plane Data Also known as “Media plane data”, or even just        “user plane” and “media plane”, this includes all RTP, RTCP and        MSRP messaging/data.

IMS-based services are initiated and released using control planesignaling or data. Control plane signaling may comprise SIP requestmethods such as INVITE or MESSAGE. Control plane signaling may be usedto send data (e.g., an SMS message) and/or to establish user planesignaling or data. User plane signaling may comprise protocols such asRTP, RTCP, or MSRP, which in turn may be used to carry media, such asIMs (e.g., text), audio data (e.g., voice or music) and/or visual data(e.g., pictures, images, or video). Both control plane signaling anduser plane signaling are transported in IP flows, which comprise IPdatagrams (and possibly a transport protocol such as UDP, TCP, or SCTP)that are routed through one or more IP networks according to the IPdatagram's IP header parameters (hereinafter also referred to as IP flowcharacteristics).

An IMS infrastructure may include a UE and an IMS network. The UE maycomprise a UICC and a mobile equipment (ME). The UICC may host one ormore applications that the ME can utilize, such as a SIM, a USIM, and/oran ISIM. The ME may also be abstracted (e.g., for the definition of ATcommands) into three further components: a TE, an MT, and a TA, e.g.,described in 3GPP TS 27.007. A UE may support AT commands, e.g., asspecified in 3GPP TS 27.007.

IP flows between a UE and a network may be transported using differentradio access technologies and/or PDN Connections, which may beidentified by APNs. PDN Connections may also be referred to as PDPContexts.

A basic UE-network architecture is depicted in FIG. 1. A UE 110 isconnected to a network 120 via an interface 130 or “reference point”.The network 120 may comprise an access network and a core network. Theaccess network may host nodes that provide a RAN between the UE 110 andthe network 120. Examples of such nodes include a NodeB, an eNodeB(eNB), a BTS, a BSC, an RNC, and an access point. The core network maycomprise a PS core network and an IMS network. A PS core network maycomprise PS nodes, such as an SGSN, a GGSN, an MME, an S-GW, a P-GW, anePDG, or an HSS/HLR. An IMS network may comprise IMS-related nodes, suchas a P-CSCF, an I-CSCF, an S-CSCF, an HSS, an AS, or an SBC/IBCF.

The reference point used between a UE and an IMS network is known as the“Gm” reference point. However, other interfaces between a UE and an IMSnetwork may exist and may be used to support that reference point andother reference points from the UE to functions within the network.

A UE may have the capability to connect to one or more types ofnetworks, such as a mobile/cellular system (e.g., 3GPP or CDMA200),WLAN/Wi-Fi, Bluetooth, USB, WiMAX, Ethernet, xDSL, or cable. The UE mayhave the capability to be connected to two or more types of networkssimultaneously, e.g., mobile/cellular and WLAN.

In a 3GPP mobile/cellular system, the UE connects to a mobile/cellularnetwork (e.g., after performing an attach or registration procedure andoptionally any authentication, authorization, and/or securityprocedures) to transport IP flows by setting up a data connection, suchas a PDP Context or a PDN Connection. In some mobile/cellular systems(e.g., LTE/E-UTRAN), a data connection is established as part of the“attach” procedure.

In a WLAN system, the UE connects to a WLAN to transport IP flows byperforming a registration or association procedure with an access pointand performing any relevant authentication, authorization, accountingand security-related procedures.

One or more policies may be used by UEs that optionally havesimultaneously active modes of operation, that is, UEs capable of havingtwo or more active data connections to two or more networkssimultaneously. Such connections may be over one or more differentaccess technologies. Similarly, a network that has two or more activedata connections simultaneously to a UE may use one or more policies todecide what access technology and/or PDN Connection is allowed,prohibited, or preferred. A policy may contain one or more rules thatindicate IP flow characteristics and one or more allowed, preferred, orprohibited access technologies and/or PDN Connections (which may beidentified by APNs) that are to be used or not be used to transport IPflows matching the criteria. An example of this feature is described in3GPP TS 22.278 and is called “IP Flow Mobility”.

The ANDSF framework is specified by 3GPP (e.g., in 3GPP TS 23.402 and3GPP TS 24.312), and its architecture may comprise one or both of afunctional entity in the home network (e.g., ANDSF-H) and afunctionality entity in the current visited cellular network/VPLMN(e.g., V-ANDSF) that can provide the UE with one or more rules (alsoknown as “policies” or just “policy”). The UE may be configured withpolicies dynamically (e.g., via a server in a carrier network acting asan H-ANDSF or V-ANDSF) and/or statically (e.g., at the time ofmanufacture or the time of firmware or OS loading).

ANDSF policies relate to different features, including what accessesand/or what APNs to use for what IP flows. ISRP and IARP are twoexamples of policies that are provided by the ANDSF framework. ISRP is aset of operator-defined rules that determine how the UE should route IPtraffic across multiple radio access interfaces. IARP is a set ofoperator-defined rules that determine which traffic should be routedacross different PDN connections as well as which traffic should benon-seamlessly offloaded to a WLAN (known as NSWO).

The ANDSF framework enables identification of IP traffic to be routedusing the criteria defined in the ANDSF MO (e.g., as defined in 3GPP TS24.312). The current criteria are shown in FIG. 2. The ANDSF frameworkenables identification of access networks, and in turn, data connectionsover those access networks, that may be used or not used to route IPflows matching the criteria of FIG. 2.

The RAN Rules framework (as specified in 3GPP TS 36.300, 3GPP TS 36.304,and 3GPP TS 36.331) allows the visited cellular network (VPLMN) to whicha UE is currently attached to provide indications to the UE if or whento “off-load” or “steer” IP flows, data, or traffic. Only IP flowsbelonging to a PDN connection for a particular APN can be offloaded to aWLAN if the traffic is currently E-UTRAN or UTRAN and the UE hasreceived an indication that the traffic using the PDN Connection or PDPContext associated with the APN can be offloaded. The framework can alsoprovide indications for the reverse case, i.e., when to use 3GPP accesstechnology to transport IP flows belonging to a PDN Connection or PDPContext associated with the APN.

Indications as to whether a PDN Connection or a PDP Context can beoff-loaded via a WLAN are provided by the MME to the UE via NASmessages. If conditions are met, the UE then off-loads all EPS bearersbelonging to the same PDN Connection (a received PDN Connection maycomprise more than one EPS bearer) via the WLAN. An indication of anoperator or carrier preference for off-load via the WLAN for the user(i.e., an OPI) may also be provided.

The IMS provides a system allowing operators to deploy media-richservices to their subscribers or users. The subscriber's or user'sdevice (UE) and the operator's network may both have to support acertain set of protocols, codecs, and other functionality. For example,both the network and the UE may need to be IMS-enabled.

After a data connection has been established between the UE and thenetwork, the UE may perform an IMS registration with an IMS network, forexample by sending a SIP REGISTER method to the network. A registrationwith the IMS network enables the UE to then be able to initiate andreceive sessions, calls (e.g., voice or audio calls or video calls), andmessages (e.g., SMS, USSD, or IM). Calls/sessions may be set up by useof SIP methods, e.g., INVITE, which may contain SDP. SDP describesmultimedia sessions for the purposes of session announcement, sessioninvitation, and other forms of multimedia session initiation. SDP mayalso be described as negotiating the media that will be used on the userplane of the call/session.

If a UE has more than one data connection connected (e.g., a PDNConnection over E-UTRAN and a WLAN association), the UE may performmultiple registrations, i.e., one for each data connection. The UE maydetect that it has multiple data connections due to having more than oneIP address assigned or active. Thus, the UE may register to IMS for oneor all of the IP addresses assigned to the UE. A data connection overwhich a UE has successfully registered to an IMS network willhereinafter be referred to as an IMS connection.

If a UE is registered over multiple IMS connections, then the UE and theIMS network can choose an IMS connection over which to establish andterminate new calls/sessions. In addition, if a UE is registered overmultiple IMS connections, the UE and/or the IMS network may also be ableto move existing IMS calls/sessions from one IMS connection to another(e.g., as defined in 3GPP TS 24.237). Such movement is referred to asIMS service continuity (IMS SC). IMS SC enables identification ofcalls/sessions to be handed over from one IMS connection to another IMSconnection using the Communication Continuity MO as defined in 3GPP TS24.216. SDP may identify the IMS calls/sessions that can be handed over.Such SDP may comprise a Media Type, as defined in IETF RFC 4566, whichmay comprise: “audio”, “video”, “text”, “application”, and “message”.The Communication Continuity MO may be used, among other things, forVoice Call Continuity (i.e., the handing over of IMS calls/sessions thatcarry only voice or audio) and Service Continuity (i.e., the handingover of any type of IMS call/session, e.g., voice, video, or IM). TheCommunication Continuity MO identifies IMS connections to whichcalls/sessions may or may not be handed over by reusing the“access-type” field defined for the P-Access-Network-Info header, asdefined in 3GPP TS 24.229.

ADS may be used by a UE or network to route a call (e.g., voice orvideo) from a UE and/or to a UE. ADS may be used to determine whether toroute calls via SIP/IMS or via the CS domain.

T-ADS is used by the network to decide how to route or deliver a call toa UE. T-ADS consists of routing incoming calls destined to the UE to afunction within the network (e.g., a SIP AS such as a ServiceCentralization and Continuity (SCC) AS). The network function thendecides what accesses are available to route the call to the UE. Thedecision may take into account such factors as CS availability (e.g.,the UE has attached to an MSC and has not missed a periodic LocationArea Update); the time of the last Location Area Update; SIP/IMSavailability (e.g., the UE has performed a successful SIP/IMSregistration and has not missed a periodic re-registration); the time ofthe last SIP/IMS registration; the capability of the underlyingtechnology conveyed to the UE during a SIP/IMS registration (e.g., ifthe UE has received an indication that voice is supported, for instancein a Tracking Area Update (TAU) Accept message or in a Routing AreaUpdate (RAU) Accept message); the time of last TAU or RAU; and/or someoperator-specific and non-standardized policy.

The UE may also support the T-ADS function by always performing (e.g.,regardless of such functions as Idle Mode Signaling Reduction (ISR) asdescribed in 3GPP TS 23.401) a TAU or RAU after moving from avoice-capable 3GPP RAT to a voice-incapable 3GPP RAT and, vice versa,when moving from a voice-incapable 3GPP RAT to a voice-capable 3GPP RAT.The RAU or TAU is performed in the new/moved-to 3GPP RAT and ensuresthat the 3GPP core network always has the most up-to-date information asto what 3GPP RAT type the UE is currently residing on, e.g., E-UTRAN orUTRAN.

The 3GPP MMTeI CDIV feature (e.g., as specified in 3GPP TS 24.604)controls redirection and rerouting of UE-destined calls/sessions in thedestination IMS network of a call/session of type voice, video, or RTTtelephony (e.g., as defined in ITU-T Recommendation T.140). CDIVcomprises a suite of services that includes, among other services,Communication Forwarding Unconditional, wherein all incomingcalls/sessions are routed to a new end point identified by a SIP URI orTel URI; Communication Forwarding on Not Reachable, wherein all incomingcalls/sessions to the destination UE are routed to a new end pointidentified by a SIP URI or Tel URI when the UE is not IMS/SIPregistered; and Communication Forwarding on No Reply, wherein allincoming calls/sessions to the destination UE are routed to a new endpoint identified by a SIP URI or Tel URI when the UE fails to respond toan incoming call/session, such as when the user does not answer theincoming call/session on the UE before a certain time elapses.

UEs may also be remotely provisioned with IMS-related policy via the IMSMO, e.g., as specified in 3GPP TS 24.167. This MO consists of manyparameters that can be managed for IMS, including the basic IMSframework (e.g., as defined in 3GPP TS 23.228 and 3GPP TS 24.229) andSMS over IMS/IP networks (e.g., as defined in 3GPP TS 24.341). The IMSMO can contain a list of ICSIs that identify an IMS CommunicationService (e.g., MMTeI or VideoCall). Stored against each ICSI in the listis an indication of whether or not the UE shall attempt to initiateresource allocation (i.e., whether the UE attempts to set up a dedicatedEPS bearer or secondary PDP Context) for the media controlled by IMSwhen a certain ICSI value is used for the IMS call/session. In addition,the IMS MO contains two leaves entitled“Voice_Domain_Preference_E_UTRAN” and “Voice_Domain_Preference_UTRAN”,which are used to indicate whether or not the UE attempts to initiateIMS voice calls/sessions over E-UTRAN and UTRAN, respectively, andwhether CS or IMS is preferred when attempting to initiate and/orreceive voice calls/sessions over E-UTRAN and UTRAN, respectively.Furthermore, the IMS MO can indicate whether the UE is prohibited frominvoking SMS over IMS or if the use of the IMS for SMS is preferred,e.g., as controlled by the “SMS_Over_IP_Networks_Indication” leaf.

The embodiments disclosed herein address at least two problems that mayarise in the above-described scenarios. First, it may not be possible toroute IP flows from different IMS services over different accesstechnologies if those component IP flows have common IP flowcharacteristics such as those listed in FIG. 2. Second, it may not bepossible to route all IP flows belonging to a single IMS service over acommon access technology if one or more of the IP flows have IP flowcharacteristics in common with an IP flow from a different IMS servicethat is routed over a particular access technology.

Regarding the first problem, it is possible that two or more differentIMS-based services can have similar or undistinguishable IP flowcharacteristics. Since only IP flow characteristics are used by existingpolicy (e.g., ANDSF or RAN Rules) for choosing what access technologyand/or APN to use to transport IP flows, operators are restricted tochoosing the same access technology and/or APN for the two or moredifferent IMS-based services. For example, an IMS-based Push-To-Talkservice and an IMS-based voice calling (e.g., voice telephony) servicemay both comprise an IP flow for audio media. It is possible and noteasily preventable that the IP flows for the audio media of bothservices could have the same IP flow characteristics. (Mandating, e.g.,that IP flow characteristics must be different for different IMS-basedservices might be unrealistic and artificially restricts the IMS-basedservices' capabilities.) In such case, it may not be possible for theoperator to specify that all media related to the IMS-based Push-To-Talkservice should use a less expensive and potentially higher delay accesstechnology (e.g., WLAN), and that all media related to the IMS-basedvoice call service should use a more expensive, lower latency,QoS-capable access technology (e.g., E-UTRAN) that is more appropriatefor delay-sensitive services.

Regarding the second problem, an IMS-based service may have two or moreIP flows, and the characteristics of at least one of the IP flows may bethe same as the characteristics of an IP flow of another IMS-basedservice. For example, the following two IMS-based services may exist:(1) an IMS-based video calling service that consists of a first IP flowfor video media and a second IP flow for audio media and (2) anIMS-based voice calling service that consists of an IP flow for audiomedia. It is possible and not easily preventable that the IP flow forthe audio media of both the video calling service and the voice callingservice could have the same IP flow characteristics. (Mandating, e.g.,that IP flow characteristics must be different for different IMS-basedservices might be unrealistic and artificially restricts the IMS-basedservices' capabilities.) In such case, it may not be possible for theoperator to specify that all media related to the IMS-based video callservice should use a less expensive but large-bandwidth accesstechnology (e.g., WLAN), and that all media related to the IMS-basedvoice call service should use a more expensive but more QoS-capableaccess technology (e.g., E-UTRAN).

Transporting different IP flows of an IMS-based service via differentaccesses and/or PDN connections may lead to one or more of the followingissues. First, latency issues may occur. That is, the packets in a firstflow may suffer a higher latency than packets in a second flow, andhence additional buffering may be needed to cover the first flow ofpackets. Also, audio may become out of sync with the visual part of avideo service (e.g., lip-sync issues may occur) due to the differentcharacteristics of the two access technologies and/or PDN Connections.Also, a new requirement may be placed on the video service clientapplication to augment data from two different sources (or “lowerlayers” of the UE). Also, billing issues may arise for the end user.That is, the user may be billed differently for the different types ofaccess used and thus may receive unexpected charges on a bill from theservice provider or carrier. For example, a user may be billed on a perbyte basis on a first access or PDN Connection and may be billed on aper service basis (e.g., the duration of a video call) on a secondaccess or PDN Connection. Additional issues may also arise.

The ANDSF MO defined in 3GPP TS 24.312 may not be suitable foraddressing the above issues. That is, identifying IP flows based only onone or more items of the IP filter information listed in FIG. 2 may notovercome the problems that may arise due to two or more IP flows havingthe possibility of being part of two different services.

In particular relation to the ProtocolType, StartDestPortNumber, andEndDestPortNumber, the ProtocolType uses a defined and well-known set ofvalues (e.g., 6=TCP, 17=UDP, etc.), while the values of theStartDestPortNumber and EndDestPortNumber for IMS media streams arenegotiated in the SDP in SIP during SIP session establishment. Forinstance, for media streams utilizing RTP (which utilizes UDP), mediastreams can use any UDP port number but typically any UDP port numberbetween 1024 and 65535 (sometimes referred to as the “UDP unprivilegedports”). Thus, uniquely identifying the media streams for one particularservice at the IP layer is only possible after the SIP session hassuccessfully been established. In other words, it may not be possible touniquely identify IMS media streams that use RTP for a particularIMS-based service using the IP filter criteria in FIG. 2 before SIPsession establishment of the IMS-based service. This in turn means thata carrier or operator cannot remotely provision a UE to reliablyidentify media streams for a particular IMS-based service using existingprovisioning methods, since existing provisioning methods commonly areincapable of provisioning a UE, during an IMS-based service call/sessionset-up or modification, with data that is valid only for thatcall/session.

In particular relation to the QoS IP filter information, differentiationbetween some IMS-based services may be achieved by configuring IP flowsbased on the QoS attribute in IP. However, since the QoS attribute islimited to DiffServ (which defines a set of code points to be used inthe ToS header field of IPv4 datagrams and the Service Class headerfield of IPv6 datagrams), this may not be sufficient to differentiatebetween all IMS-based services, since there is no guarantee that IPflows belonging to two different IMS-based services will have differentDiffServ settings in the IP datagram's ToS (as found in IPv4) or ServiceClass (as found in IPv6) IP datagram header field.

Within 3GPP, the use of QCI values in place of DiffServ values in theQoS attribute has been discussed. However, among other issues with thisapproach, the same issue as for using DiffServ values may apply if QCIvalues instead of DiffServ values were used in the ToS and Service ClassIP datagram header fields. Moreover, since IP flows relating tovoice-only service use only one QCI value (a value of 1), and IP flowsrelating to a combined audio and video service use two QCI values (avalue of 1 for the audio part and a value of 2 for the video part),steering IP flows for voice to a different access or PDN Connection fromthe IP flows for video could cause the audio media and the video mediaof the video service to be transported over different accesstechnologies or PDN Connections. Such a difference may lead to a numberof issues, as discussed above, due to the different characteristics ofthe two access technologies and/or PDN Connections.

In addition, the ANDSF framework allows identification of IP flows inthe UE based on the OS application (“app”) identifier (“ID”) of theUE-internal application that is originating and terminating a particularIP flow. A drawback relating specifically to differentiating IP flowsbased on OS app ID is that the values assigned to OS app IDs are notstandardized and can differ between different operating systems of UEs.OS app IDs are also subject to change. For example, a new version of anapp may be assigned a new value for its OS app ID. Furthermore, only theUE knows the OS app ID. That is, the ID is not communicated in signalingor messaging to or from the UE. Therefore, any external party to the UE(e.g., a carrier) may have difficulty in discovering the OS app ID thatis originating and terminating IP flows, which in turn makes anyconfiguration of which access each OS app should use very difficult.

Also, for EPC-connected access networks (e.g., EPC-connected Wi-Fi orEPC-connected WLAN), the APN that is to be used to route IP flows (whichin itself is assigned traffic by the aforementioned IP-relatedcharacteristics and OS app ID) can be used.

It may be noted that, today, when data connections on a cellular networkand on an EPC-connected WLAN are available to a UE, seamless wirelessoffload may occur (such handovers may also occur in other situations).However, the same drawbacks described above with respect to using IPflow characteristics and OS app ID may apply in such cases, since IPflow characteristics and/or OS app ID are used to decide which IP flowsare to be transported over which PDN Connection.

The Communication Continuity MO defined in 3GPP TS 24.216 may also beunsuitable for addressing the issues described above. The CommunicationContinuity MO currently only defines what data connections can be usedto hand over existing IMS calls/sessions. That is, this MO does notinfluence which data connection is used to initiate an IMS call/session.An operator that wants to use this MO for controlling what access a UEuses only for call/session initiation may be forced to populate fieldsfor handover regardless of whether or not the operator wants to managehandover or whether or not the operator wants to request or implementnon-standard behavior or functionality on the UE. Another drawback ofusing this MO may be that this MO uses SDP to identify IMScalls/sessions, which can make the MO long and convoluted. Yet anotherdrawback of using this MO may be that there can be overlaps or conflictsbetween IMS calls/sessions that can be handed over as identified usingthis MO and IP flows identified using the ANDSF MO. Currently, suchconflicts are assumed to be avoided by careful operator configuration.However, since an H-ANDSF and V-ANDSF can provide policy to the UE,there is a greater risk of policy conflicts due to the HPLMN having toensure its policy does not conflict with all of its VPLMN roamingpartners and vice versa.

The IMS MO defined in 3GPP TS 24.167 may also be unsuitable foraddressing the issues described above. The IMS MO only provides controlfor access transport for voice and SMS. For voice, this is limited toonly IMS versus CS when the current access technology is only E-UTRAN orUTRAN. For SMS, this is limited only to whether to attempt using IMS ornot (e.g., preferring SMS over PS, SMS over CS, and/or SMS over SGs toSMS over IMS). Furthermore, despite the IMS MO being able to hold a listof ICSIs, the only indication associated with the ICSIs is an indicationas to whether or not to make an attempt to initiate resource allocationfor the media controlled by IMS.

MMTeI CDIV may also be unsuitable for addressing the issues describedabove. CDIV is a feature that is used solely by a terminating network(i.e., the home network of a destination UE) within a call/session. Thatis, CDIV is limited only to MT sessions in the MT network and is furtherlimited in that it only applies for voice calls, video calls, and RTT.In addition, CDIV is unable to cope with redirecting calls/sessions onconditions related to access technology. For example, CDIV is unable toredirect calls/sessions over specific accesses. Instead, CDIV justredirects incoming calls/sessions to a specific target (e.g., a SIP URIor a Tel URI) unconditionally, based on conditions of the user'savailability/reachability or at the user's request such as upon the UEalerting the user to an incoming call/session.

ADS may also be unsuitable for addressing the issues described above.ADS is currently limited only to voice and video calls and can only beused to select between CS and IMS. That is, ADS cannot be used to selectbetween different IMS connections or data connections. Hence, ADS cannotbe used to select between different accesses used for IMS data.

IP flows can also be managed using the “RAN Rules” framework, but RANRules may be unsuitable for addressing the issues described above. Afirst drawback of using the RAN Rules framework as currently defined isthat this framework is limited only to data connections via E-UTRAN,UTRAN, and WLAN. In addition, this framework off-loads all IP flowsrelating to specific APNs. That is, this framework performs trafficsteering between E-UTRAN/UTRAN and WLAN with only an APN granularity,i.e., steers all EPS bearers belonging to the same APN. APN selection isbased on IP parameters, and therefore the restrictions discussed abovewith regard to the ANDSF MO may also apply to the RAN Rules framework. Asecond drawback to using the RAN Rules framework is that the UE must beconnected to a cellular network to receive the necessary steering orrouting information. In other words, in the absence of a data connectionto a cellular network, this solution does not function.

One or more embodiments are disclosed herein that may address the issuesdiscussed above. In an embodiment, a UE is provisioned with or receivesan IMS Transport Policy. The IMS Transport Policy may contain an IMSService Identifier, such as an ICSI (preferred), an IARI (which mayidentify an application that uses one or more IMS services), and/or SDP.Additionally or alternatively, the IMS Transport Policy may specifyallowed and/or prohibited/barred radio access technologies and/or APNs,with an indication of preference or order if there are multipleinstances. A special or reserved value may be used to indicate allpossible radio access technologies and/or APNs.

In addition to the above, the IMS Transport Policy may provide anindication of whether one or both of the IMS control plane and IMS userplane data are applicable. Such an indication may also be providedimplicitly by the absence of a specific indication.

As part of the transport policy provisioning, a UE may receive a list ofservices to which transport policies apply. If a service is not listed,then the UE is permitted to use any UE-determined transport withoutregard to the presence or absence of a transport policy for thatservice. Such permission may ensure continued use of proprietaryservices that are not standardized and/or known to operators.

In addition, the IMS Transport Policy may include an indication that theIMS Transport Policy shall take priority over other, existing transportor routing policies already present on the UE, such as those that mayhave been provisioned on the UE using existing methods (e.g., OMA DM orSIM OTA). Such existing policies may include, for example, ISRP and/orIARP.

The IMS Transport Policy may be provided in response to a UE initiatinga service, such as in a case where the network has not already indicatedthat the service is subject to a policy. In this case, for example, theIMS Transport Policy may be provided responsive to the initiation toindicate that the UE should use a specific policy for the initiatedservice. The policy may be determined based on the identification ofspecific codecs (e.g., video codecs) in the SDP signaling messages.

A UE may invoke an IMS-based service (e.g., call initiation or sessioninitiation) or modify an existing IMS-based service for various reasons,such as due to end user interaction with the UE, an AT command beingissued to the UE, etc. Responsive to such an invocation or modification,several steps may be taken. First, the UE may create a relevant SIPrequest method (e.g., INVITE or MESSAGE) to initiate an IMS-basedservice. Second, the UE may look up and retrieve an IMS Transport Policyusing the preferred ICSI (i.e., the ICSI included in theP-Preferred-Service header field) from the SIP method created in thefirst step. The UE may also retrieve other header field contents and SIPmessage body contents (e.g., SDP) of the SIP method. Third, the UE maycreate one or more IP-related routing policies (e.g., ISRP and/or IARPrules) using an IMS Transport Policy retrieved in the second step thatcontains policy rules relating to control plane traffic. Hereinafter,such routing policies will be referred to as “dynamically createdrouting policies for the control plane”. The UE may use AT commands todynamically create routing policies for the control plane. Fourth, theUE may send the created SIP method to lower layers, which may thentransport the SIP method from the UE to the IMS network using an accesstechnology or PDN Connection (as identified by an APN) as indicated bythe dynamically created routing policies for the control plane.

Fifth, after SIP session establishment, the UE may decide or need tocreate more IP-related routing policies (e.g., if there is user planedata to transport between the UE and IMS network, the retrieved IMSTransport Policy from step #2 contains policy rules that apply to userplane traffic). For example, the UE may create policies such as ISRPand/or IARP rules based on information in the IMS Transport Policyand/or on IP-related information negotiated in the SIP signaling thatcreated the SIP session. Such information may include, but is notlimited to, ports negotiated in SDP to be used for media, such as RTP,RTCP, MSRP, etc. The UE may create such additional policies to ensurethat all user plane data IP flows are uniquely identified for theservice and that the IP flows use an allowed and preferred accesstechnology or PDN Connection (as identified by an APN), and do not useprohibited accesses or PDN Connections. Hereinafter, such policies willbe referred to as “dynamically created routing policies for the userplane”. The UE may use new or enhanced AT commands to dynamically createrouting policies for the user plane.

Creating dynamically created routing policies for the user plane afterSIP session establishment allows for more accurate IP-related policy inthe UE in that one or more transport layer port numbers may be known(e.g., from the SDP) and may be reliably set in the IP layer policy,thus preventing conflicts or overlaps with IP flows for other services.

Optionally, instead of using the ICSI from the IMS Transport Policy thatis provisioned to or received at the UE in the first step discussedabove, the UE may use header field information and message body contents(e.g., SDP) that are currently provided, e.g., in a 200 OK SIP responsemessage. Alternatively or additionally, the UE may use an ICSI orinformation derived from an ICSI. Such information may be received fromthe network or provided in a SIP Response message. The SIP Responsemessage may be, for example, a 200 OK response message that has beenenhanced to include an ICSI. Such an ICSI may be the same as ordifferent from the preferred ICSI from the first step. Alternatively,the 200 OK response message may be enhanced to include informationderived from the asserted ICSI within the network. In the cases wherethe UE uses information derived from an ICSI, the indication receivedfrom the network may not be referred to as an ICSI but may be anyreference that corresponds to a previously provided transport policy.

Sixth, the UE may then send any user plane data to the IMS network usingan access technology or PDN Connection (as identified by an APN) asindicated by the IMS Transport Policy and/or the dynamically createdrouting policies for the user plane.

The steps discussed above are pictorially represented in the flowdiagram in FIG. 3. At block 302, a UE receives an IMS Transport Policy.At block 304, the UE waits for an invocation of a new IMS-based service,or a modification of an existing IMS-based service. At block 306, the UEcreates a SIP method or SIP request. At block 308, the UE looks up andretrieves an IMS Transport Policy using the preferred ICSI (e.g., ICSIincluded in a P-Preferred-Service header field). At block 310, the UEdetermines whether an IMS Transport Policy exists for the control planefor the preferred ICSI. If such an IMS Transport Policy does exist, thenthe procedure moves to block 312, where the UE dynamically creates oneor more routing policies for the control plane. The procedure then movesto block 314, where the UE sends the SIP request/method to lower layersin order to be sent to the network. If, at block 310, it is determinedthat such an IMS Transport Policy does not exist, then block 312 isbypassed and the procedure moves directly to block 314. After block 314,the procedure moves to block 316, where the UE waits for SIP dialogueconfirmation, such as a 200 OK message. Then, at block 318, it isdetermined whether user plane data is required. If user plane data isnot required, the procedure ends. If user plane data is required, theprocedure moves to block 320, where it is determined whether IMSTransport Policy exists for the user plane for the preferred ICSI. Ifsuch an IMS Transport Policy does exist, the procedure moves to block322, where the UE dynamically creates one or more routing policies forthe user plane. The procedure then moves to block 324, where the UEsends the user plane data to lower layers in order to be sent to thenetwork. The procedure then ends. If, at block 320 it is determined thatan IMS Transport Policy for the user plane does not exist, then theprocedure moves directly to block 324.

Responsive to UE-initiated or IMS network-initiated disconnection orrelease of a session for an IMS-based service (e.g., call release orsession release) as established in the steps above, the UE may thenremove all or a subset of the dynamically created routing policies forthe control plane and/or all or a subset of the dynamically createdrouting policies for the user plane. In some aspects, the UE may alsouse IMS Transport Policy to determine if the UE is allowed or prohibitedto perform a SIP/IMS registration over a particular transport.

Details will now be provided regarding the embodiments described above.Details regarding the structure of an IMS Transport Policy will bedescribed first.

IMS Transport Policy may comprise one or more sets of IMS servicetransport rules, where a set of IMS service transport rules may compriseat least an indication of one or more IMS-based services and anindication of one or more access transports that are allowed/prohibitedand/or preferred over other access transports. Therefore, a set of IMSservice transport rules may be defined as containing at least ServiceIndication Data (SID) and Transport Indication Data (TID). The SID maycomprise an indication of one or more IMS-based services. The TID maycomprise an indication of one or more transports that can/cannot and/orare preferred to be used to transport or transmit or route (e.g.,between a UE and a network) IP flows or data relating to one or moreIMS-based services indicated in the SID. The transports may be accesstechnologies and/or PDN Connections. Example access technologiesinclude, but are not necessarily limited to, mobile/cellular (e.g.,2G/GERAN, 3G/UTRAN, 4G/LTE/E-UTRAN, or CDMA2000), Wi-Fi/WLAN (e.g., IEEE802.11-based technologies), Bluetooth, NFC, WiMAX, wireless chargers,Ethernet, cable modem, DSL, fiber, USB, and wireless USB. The PDNConnections may be identified by, for example, an APN, an NSAPI, etc.

An example of an IMS Transport Policy structure is illustrated in FIG.4, which shows an IMS Transport Policy 400 that contains two sets ofservice transport rules 410A and 410B, each of which in turn contains aSID portion 420A and 420B and a TID portion 430A and 430B, respectively.The IMS Transport Policy 400 may also be referred to herein as an IMStransport policy set. A SID (e.g., 420A, 420B) may also be referred toherein as an indication of at least one IMS service. A TID (e.g., 430A,430B) may also be referred to herein as an indication of a policy for atleast one access technology associated with the at least one IMSservice.

In addition to the SID and TID components, or as an alternative to theTID component, an indication may be provided to indicate an allowance orprohibition as to whether one or more IMS-based services indicated inthe SID component may be transported or off-loaded to a WLAN frommobile/cellular networks. Such indication may be referred to hereinafteras an “Offload Indication”.

If a TID component contains multiple transports, then each transport maybe associated with a particular weighting or preference, which maycomprise a field that contains a value (e.g., a number where the lowerthe number is, the higher the preference, or vice versa). In someimplementations, such weighting or preference may be derived implicitlysuch as by a specific ordering of the transports in the TID component.The TID component may also or alternatively contain an indication forsome or all transports contained within the TID component, theindication indicating whether the transports can be used by the serviceidentified in the SID when the device is disabled from using cellular PSdata (e.g. “Data Off” mode in the UE).

A set of IMS service transport rules may contain additional and/oralternative components. One such component may be an indication of oneor more Network Identities (e.g., PLMN code, WLAN identity, or NAI) orcountry identities (e.g., MCC) to which the set of IMS service transportrules is applicable. Another such component may be an indication of atime period in which the set of IMS service transport rules may orshould or can or shall be used. For example, one or more specific dates,months, years, times of day, and/or frequency/occurrence (e.g., daily,weekly, monthly, or yearly) may be indicated. The date and time in theUE or an attached network may be used. Another such component mayindicate a weighting or preference of a set of IMS service transportrules relative to other sets of IMS service transport rules within theIMS Transport Policy. The weighting or preference may be indicated via afield that contains a value, or implied via a specific ordering of theset of IMS service transport rules in the IMS Transport Policy. Anothersuch component may be an indication of whether the set of IMS servicetransport rules applies to one or both of outgoing calls/sessions andincoming calls/sessions. Another such component may be an indication ofwhether the set of IMS service transport rules applies to a modificationof an existing call or session. Such a component may optionally indicateif the set of IMS service transport rules are reapplied when, forexample, media is added to an existing call/session, media is deletedfrom an existing call/session, and/or existing media is modified in anexisting call/session (e.g., a change of codec for a voice or video callor a change of content in an IM session).

A SID component may also include additional components, such as, but notlimited to, one or more of: a SID Identifier, which may be one or morecharacters or one or more bytes/octets comprising data representing oneor more numbers, letters, or both numbers and letters; one or moreICSIs, such as those defined in 3GPP TS 23.228 and 3GPP TS 24.229; oneor more IARIs, such as those defined in 3GPP TS 23.228 and 3GPP TS24.229; one or more feature tags; one or more media feature tags, suchas those defined in 3GPP TS 24.229 or IETF RFC 3840; one or more SDPdescriptions (also known as an “SDP message body”); one or morecomponents of an SDP description, such as a codec list; one or more SIPMethods or SIP request types; and/or one or more SIP responses.

Alternatively or additionally, the SID or TID may comprise a “MappingCode” that is defined as one or more characters (e.g., a characterstring) or one or more bytes/octets that comprise data representing oneor more numbers (e.g., numeric code), letters (e.g., alphabetic code),or both numbers and letters (e.g., alphanumeric code). The Mapping Code,when used in a SID, may have a defined mapping to one or more SIDcomponents and, when used in a TID, may have a defined mapping to one ormore TID components. For example, the Mapping Code may be or contain aSID Identifier or TID Identifier.

Populating the SID with a Mapping Code instead of an indication of oneor more IMS-based services and populating the TID with a Mapping Codeinstead of an indication of one more transports may provide efficienciesregarding the length of an information element (IE), or parameter,attribute, Attribute Value Pair, variable, container, header field, etc.That is, a message that contains a SID with a Mapping Code component maybe made shorter than if the SID contained an ICSI, IARI, SDPdescription, components of an SDP description, and/or SIP Methods.Likewise, a message that contains a TID with a Mapping Code componentmay be made shorter than if the TID contained a list of one or moretransports. Use of a Mapping Code may also allow an entity external to aUE to more easily update previously stored IMS Transport Policy on theUE.

Information regarding whether the SID of a set of IMS service transportrules contains a Mapping Code or an indication of one or more IMS-basedservices and whether the TID of a set of IMS service transport rulescontains a Mapping Code or an indication of one more transports may bepre-configured. Alternatively, such information may be determined (e.g.,by a UE) by analyzing a portion of the SID or TID. For example, apredefined component, portion, element, character, field, informationelement, or sub-field may be analyzed for a particular value e.g., afirst character or digit, a last character or digit, etc. Alternatively,such information may be determined (e.g., by a UE) by analyzing all ofthe SID or TID. For example, the length of the SID or TID may beanalyzed, or the contents of the SID or TID may be analyzed to matchagainst a known value, pattern, or format associated with a MappingCode.

If it is determined that a SID of a set of IMS service transport rulescontains a Mapping Code, the Mapping Code may be translated (e.g., by aUE) to an indication of one or more IMS-based services (e.g., by using alook-up table, a hash table, a hash function, or a look-up to a server).The translating device may also store the association of the MappingCode and the indication of one or more IMS-based services.Alternatively, the device may store the mapped-to indication of one ormore IMS-based services in place of the Mapping Code in the SIDcomponent that originally contained the Mapping Code.

If it is determined that a TID of a set of IMS service transport rulescontains a Mapping Code, the Mapping Code may be translated (e.g., by aUE) to an indication of one or more transports (e.g., by using a look-uptable, a hash table, a hash function, or a look-up to a server). Thetranslating device may also store the association of the Mapping Codeand the indication of one or more transports. Alternatively, the devicemay store the mapped-to indication of one or more transports in place ofthe Mapping Code in the TID component that originally contained theMapping Code.

As an alternative implementation, the Mapping Code may identify a set ofIMS service transport rules whereby the same functionality as describedabove would be applicable. However, in this instance, the Mapping Codemay identify more data, such as a SID and a TID; a SID and an OffloadIndication; a SID, a TID, and an Offload Indication; etc.

FIG. 5 shows a diagrammatic view of the manner in which an IMS TransportPolicy 510 may be stored in a UE according to an embodiment. In thisrepresentation, the TID component 520 has been split out into twocomponents denoted as “APN?” 530 and “RAT?” 540 in FIG. 5. Analternative representation of the manner in which an IMS TransportPolicy 610 may be stored in a UE is shown in FIG. 6.

One skilled in the art will appreciate what each of the boxes in FIG. 5and FIG. 6 may represent. For example, a box containing a “?” indicatesthat the data item is optional, and a box containing an <x+> indicatesthat the data is selected from a list of entries ranging from 0 to 1 ormore entries. Furthermore, the IMS Transport Policy data structure treemay be a subcomponent of any data structure trees or new trees that aredefined in 3GPP management objects.

Details regarding the provisioning of a UE with IMS Transport Policy(e.g., as in block 302 in FIG. 2) will now be provided.

In a first approach, a UE retrieves IMS Transport Policy from a file ona UICC. This approach may be referred to as Provisioning Method A. In asecond approach, a UE retrieves IMS Transport Policy from an entityexternal to the UE, such as a server. This approach may be referred toas Provisioning Method B.

Under Provisioning Method A, a UICC (which may be an embedded UICC(eUICC)) within or associated with a UE is provisioned with IMSTransport Policy by the UICC owner (e.g., a carrier or an operator). Theprovisioning of the UICC may be performed during the manufacturingprocess of the UICC, using a UICC remote provisioning mechanism (e.g.,SIM OTA, Remote Provisioning of eUICC profiles), or by some other means.A mobile entity (ME) may retrieve the UICC-provisioned IMS TransportPolicy from the UICC at any time, such as upon UEwake-up/switch-on/power-up, upon insertion of an insertable/removableUICC, or upon activation of a new SIM/USIM application on a UICC oreUICC.

FIG. 7 depicts one possible embodiment of how data may be encoded on theUICC (e.g., using a USIM as defined in 3GPP TS 31.102 or using an ISIMas defined in 3GPP TS 31.103). However, it is to be understood that datacould also be encoded using any of the mechanisms described herein.

Under Provisioning Method B, a UE is able to retrieve IMS TransportPolicy remotely from an entity external to the UE in the network. Suchan entity may be referred to hereinafter as a “network node” or a“network element”. (FIG. 9, which will be discussed in more detailbelow, provides examples of what such a network node may be). Forexample, the UE may send the network node a request message providing avariety of information that may be used by the network node to tailorthe IMS Transport Policy. Such information may be referred tohereinafter as “Additional UE Provided Information”. The IMS TransportPolicy may then be returned to the UE in a response message to therequest message.

The request message sent to the network node by the UE to request IMSTransport Policy may be, for example, a message before the UE registerswith the network (e.g., an ANQP request), a registration-type message(e.g., Attach or TAU/RAU), a data session establishment message (e.g., aPDN Connection, PDP Context activation, setup, modification, orrequest), a dedicated message for retrieving IMS Transport Policy, etc.

The protocols utilized by the request message and/or response messagemay include one or more of Non-Access Stratum signaling (e.g., asdefined in 3GPP TS 24.008 and 3GPP TS 24.301), RADIUS, Diameter, LDAP,SQL, DNS, DHCP, GTP, SOAP, XML, HTTP, SIP, SDP, OMA DM, SIM OTA, or SIMToolkit.

The IMS Transport Policy may be stored in the network node that receivedthe request message from the UE (referred to hereinafter as the “firstnetwork node”), or the IMS Transport Policy may be obtained from anothernetwork node (referred to hereinafter as the “second network node”). Thesecond network node may be connected directly to the first network node,or may be connected indirectly via one or more other intermediatenetwork nodes (e.g., servers or proxies). Upon receiving a request fordata, the second network node may return the data to the first networknode either directly or indirectly via one or more other intermediatenetwork nodes.

FIG. 8 illustrates the messaging between a UE 810, a first network node(denoted as “Network Node #1” 820), and a second network node (denotedas “Network Node #2” 830). The message flow sequences in FIG. 8 areillustrative only, as other orderings of the messages are possible.

In a first permutation 840, the UE 810 sends Message #1 to Network Node#1 820. Message #1 may contain Additional UE Provided Information. Uponreceiving Message #1, Network Node #1 820 may send an optional messagesuch as Message #2 to Network Node #2 830. Message #2 may containAdditional UE Provided Information, such as if received in Message #1.Upon receiving Message #2, Network Node #2 830 sends Message #3 toNetwork Node #1 820. Message #3 may contain IMS Transport Policy, anerror message, or both. Upon receiving Message #3, Network Node #1 820sends Message #4 to the UE 810. Alternatively, since Message #2 isoptional, Network Node #1 820 may send Message #4 in response toreceiving Message #1. Message #4 may contain IMS Transport Policy, anerror message, or both, e.g., depending on what information was receivedin Message #3.

In a second permutation 850, Network Node #1 820 sends Message #2 toNetwork Node #2 830. Message #2 may contain Additional UE ProvidedInformation, e.g., if previously received from the UE 810. Uponreceiving Message #2, Network Node #2 830 sends Message #3 to NetworkNode #1 820. Message #3 may contain IMS Transport Policy, an errormessage, or both. The UE 810 sends Message #1 to Network Node #1 820.Message #1 may contain Additional UE Provided Information. Uponreceiving Message #1, Network Node #1 820 sends Message #4 to the UE810. Message #4 may contain IMS Transport Policy, an error message, orboth, e.g., depending on what information was received in Message #3.

In a third permutation 860, Network Node #2 830 sends Message #3 toNetwork Node #1 820. Message #3 contains IMS Transport Policy. Uponreceiving Message #3, Network Node #1 820 sends Message #4 to the UE810. Message #4 contains IMS Transport Policy (e.g., as received inMessage #3). Upon receiving Message #4, the UE 810 sends Message #1 toNetwork Node #1 820. Message #1 may contain Additional UE ProvidedInformation. Upon receiving Message #1, Network Node #1 820 may sendMessage #2 to Network Node #2 830. Message #2 may contain Additional UEProvided Information (e.g., if received in Message #1).

In a fourth permutation 870, Network Node #2 830 sends Message #3 toNetwork Node #1 820. Message #3 contains IMS Transport Policy. Uponreceiving Message #3, Network Node #1 820 may send Message #2 to NetworkNode #2 830. Message #2 may contain Additional UE Provided Information(e.g., if previously received from the UE 810). Upon receiving Message#3, Network Node #1 820 sends Message #4 to the UE 810. Alternatively,Network Node #1 820 may not necessarily send Message #4 to the UE 810 inresponse to receiving Message #3, but may instead send Message #4 basedon some other event, such as a Tracking Area Update procedure performedby the UE 810. Message #4 contains IMS Transport Policy (e.g., asreceived in Message #3). Upon receiving Message #4, the UE 810 sendsMessage #1 to Network Node #1 820, and Message #1 may contain AdditionalUE Provided Information.

The first permutation and second permutation may be used in a “fetch” or“get” or “pull” type architecture. The third permutation and fourthpermutation may be used in a “put” or “post” or “push” typearchitecture.

Examples of what Network Node #1 and Network Node #2 may be are providedin FIG. 9. Examples of what Messages #1-4 may be are provided in FIG.10.

An example of “Additional UE Provided Information” discussed herein mayinclude, but is not limited to, the following: an indication that IMSTransport Policy is requested by the UE; an indication as to whattransport or transports for which the UE requires IMS Transport Policy;an indication as to what transport or transports the UE supports; anindication as to what transport or transports to which the UE currentlyhas access or are active in the UE and/or are connected; an indicationas to what transport or transports to which the UE currently has noaccess or are inactive in the UE and/or are disconnected; an indicationof the UE's capabilities (e.g., IFOM, MAPCON, OPIIS, etc.); anindication of the transport or transports for which the UE has aconfiguration; and/or an indication of Network Identities such as thoseto which the UE has access, those with which the UE is registered,and/or those for which the UE has a configuration.

AAA messages using EAP may be used to obtain the transport policy. Theexisting IETF document “draft-mccann-session-policy-framework-using-eap”describes the use of AAA messages to obtain a session policy. Similarmessages may be used in this and/or other embodiments.

The use of SIP signaling (e.g., SUBSCRIBE/NOTIFY) may be employed as analternative solution based on either a new policy event package for thetransport policy or an extension to the registration event package (see3GPP TS 24.229) or to the session policy event package (see IETF RFC6795).

Two example implementations of provisioning IMS Transport Policy to a UEare shown in FIG. 11 and are labelled “A” and “B”. In these examples,the UE 1110 is provisioned with IMS Transport Policy based on anLTE/E-UTRAN Attach procedure. The numbers assigned to the messages inFIG. 11 have a direct correlation to the message numbers denoted in FIG.8.

The box 1120 labelled “Optional Update Location procedure” denotes thatan Update Location Procedure or Tracking Area Update Procedure orRouting Area Update Procedure or Location Area Update procedure may, butneed not, take place before the messages denoted 1, 2a, 2b, 3a and 3b.For example, the UE may have already registered to the MME 1130 and maybe attaching again. If such a procedure is performed, then 2 and 3 inimplementation “A” would occur before 2a, 2b, 3a and 3b.

In the implementation labelled “A”, the UE attaches to the network,optionally sends Additional UE Provided Information in the Attachmessage, and then receives IMS Transport Policy in the Attach Acceptmessage. The IMS Transport Policy may be stored in the HSS 1140 and maybe downloaded or transferred to the MME 1130.

The implementation labelled “B” is the same as implementation “A” exceptthat the IMS Transport Policy is sent from the P-GW 1150 to the MME1130. The P-GW 1150 may have obtained the IMS Transport Policy from thePCRF 1160.

An additional example implementation of IMS Transport Policy beingprovisioned to a UE is shown in FIG. 12 and is labelled “C”. In thisexample, the UE 1210 is provisioned with IMS Transport Policy during aPDP Context Activation procedure. The numbers assigned to the messagesin FIG. 12 have a direct correlation to the message numbers denoted inFIG. 8.

In Implementation C, the UE 1210 optionally sends Additional UE ProvidedInformation in the Activate PDP Context Request message and thenreceives IMS Transport Policy in the Activate PDP Context Responsemessage. The IMS Transport Policy may be stored in the SGSN 1220 afterbeing downloaded from the GGSN 1230. The GGSN 1230 may download the IMSTransport Policy from the PCRF 1240. Other functional entities may alsobe involved, e.g., HLR/HSS.

Implementations A, B and C may also be used to update IMS TransportPolicy that was previously downloaded (by, e.g., Implementation A,Implementation B, Implementation C, or another mechanism) in addition oras an alternative to downloading new IMS Transport Policy. Such updatingallows for a more optimized method of delivering the information,whereby the information can be tailored to the actual PDP Context or PDNConnection being used. In this case, one or more Mapping Codes may beused in downloaded IMS Transport Policy.

One skilled in the art will appreciate that while Implementations A, Band C are specific examples, the messages may be different, e.g.,messages according to Messages #1, #2, #3 and/or #4 in FIG. 10 may beused in some implementations.

Details regarding the use of IMS Transport Policy by a UE will now beprovided.

Once IMS Transport Policy has been received by the UE (e.g., using oneof the methods described herein), the IMS Transport Policy may be storedby the UE in such a way that the IMS Transport Policy can be retrievedor referenced. That is, the IMS Transport Policy may be temporarily orpermanently stored in the device or in storage associated with thedevice, such as internal memory or storage (e.g., RAM or Flash RAM).Alternatively, storage may occur in an external data card, such as in afile or application stored on a UICC/SIM card or R-UIM (e.g., SIM, USIM,or ISIM) or such as in a file stored on a removable memory card (e.g., aMicroSD memory card). Two example embodiments of storage comprise anANDSF data structure and a UICC file, as described herein.

In some implementations, the UE may delete all or a subset of IMSTransport Policy when one or more of the following event occurs: the UEis powered off or loses power; the UICC/SIM card or R-UIM is removedfrom or replaced in the UE; new IMS Transport Policy is received; the UEdetaches from a network, such as a cellular network (PLMN) or a WLAN;the UE or the network deactivates, tears down, or deletes a dataconnection, such as PDP Context, EPS/PDN Connection, EPS Bearer, or TCPassociation; and/or the UE or the network deregisters the UE from IMS.

At any time, a user, process or service may initiate the UE to perform aSIP/IMS registration over a particular transport. Upon initiation of theregistration, but before the registration operation is commenced (e.g.,before a SIP REGISTER is sent by the UE to the network), the UE maycheck for the particular transport in the UE's stored IMS TransportPolicy.

If the UE's stored IMS Transport Policy does not contain the particulartransport (i.e., if there are no sets of IMS service transport rulesthat contain the particular transport), then the UE may be allowed toperform the SIP/IMS registration (e.g., to permit backwardscompatibility). Alternatively, the UE may be prohibited from performingthe SIP/IMS registration, e.g., based on other policies, configurations,or settings available to the UE, which should indicate that the networksupports the use of a transport policy solution.

If the UE's stored IMS Transport Policy does contain the particulartransport (i.e., if one or more sets of IMS service transport rules havea matching transport in their TID component), then the IMS-basedservices indicated in the IMS service transport rules that contain theparticular transport in their TID component may be indicated in theSIP/IMS registration. For example, a SIP REGISTER that contains one ormore of an ICSI, IARI, feature tag, or media feature tag may be sent bythe UE to the network.

If SIP is used to obtain the transport policy, then the UE may need tocomplete SIP registration. However, the UE may subsequently need tore-register after having obtained the policy, specifically if the UE isrequired to use a different access network (in accordance with thepolicy).

As an optional enhancement, the UE may not perform the SIP/IMSregistration if the stored IMS Transport Policy does not contain theparticular transport for any IMS-based service and/or if the IMSTransport Policy prohibits the particular transport for all IMS-basedservices. In such a case, the UE may indicate to the user and/or toupper protocol layers in the UE that SIP/IMS registration is denied orprohibited.

At any time after at least one successful SIP/IMS registration hasoccurred, a user or process or service may initiate the UE to performone or more actions. For example, the UE may be initiated to establish anew call/session for a particular IMS-based service, such as initiationof a voice/VoLTE call or initiation of a video/ViLTE call. Alternativelyor additionally, the UE may be initiated to modify an existingcall/session for a particular IMS-based service, such as modifying anexisting voice/VoLTE call to change or upgrade to a video/ViLTE call ormodifying an existing voice/VoLTE call to use a different codec ordifferent codec settings. Alternatively or additionally, the UE may beinitiated to send a message for a particular IMS-based service, such assending an SMS message or sending an Instant Message.

After the initiation but before the establishment of the newcall/session, the modification of the existing call/session, or thesending of the message, the UE may determine whether an IMS-basedservice associated with the new call/session, modified call/session, ormessage to be sent is mentioned in the UE's stored IMS Transport Policy.The UE may also check what transports are available to the UE totransport IMS control plane IP flows/data. The check of the IMSTransport Policy and the check of available transports may be performedin any order. The UE may also perform similar checks but for IMS userplane IP flows.

A transport is considered to be available to the UE to transport IMScontrol plane IP flows or IMS user plane IP flows if the transport haspreviously been used to perform an IMS/SIP registration (e.g., asspecified in 3GPP TS 24.229 and IETF RFC 3261). In such a case, the IMShas a binding of the UE to that transport, such as the UE's IP address,for an interface for the transport with SIP/IMS credentials (e.g.,Private User Identity or Public User Identities or Reg-Id or InstanceIdor GRUU). This consideration includes transports that can be offloaded,transferred, or handed over between access technologies without the UEneeding to use a different IP address. For example, a PDN Connection toa particular APN (e.g., an IMS well-known APN) over one accesstechnology (e.g., E-UTRAN) may have been used by the UE to perform anIMS/SIP registration, and the PDN Connection to the particular APN maythen have been offloaded or handed-over some time later to a differentaccess technology (e.g., Wi-Fi or WLAN).

A transport may also or alternatively be considered to be unavailable ifthe UE has been disabled from using PS cellular data (e.g., “Data Off”mode is enabled on the UE); or the transport may be considered availableand a component of the TID(s) of the selected set of IMS servicetransport rules (as defined below) may be used to determine if thetransport may be used by the service(s) identified in the SID(s) of theselected set of IMS service transport rules while the UE has beendisabled from using PS cellular data.

If no transports are available to the UE to transport IMS control planeIP flows and/or IMS user plane IP flows, and the UE has determined thatthe network supports the provision of a transport policy, then at leasttwo conditions may apply. First, if a new call/session was to beestablished, then the new call/session fails or is prohibited from beingestablished. Second, if a message was to be sent, then the message failsor is prohibited from being sent. In both of these cases, the ComparisonProcedure, as described below, may be omitted by the UE.

In the case of initiating a modification to an existing call/session, itmay be assumed that at least one transport is available to transport IMScontrol plane IP flows. That is, the transport currently being used totransport the IMS control plane IP flows for the existing call/sessionmay be available. It may also be assumed that there is at least onetransport available to transport any IMS user plane IP flows. That is,the transport currently being used to transport the IMS user plane IPflows for the existing call/session may be available.

The UE may select a set of IMS service transport rules from the storedIMS Transport Policy by attempting to match one or more elements of theSID (e.g., an ICSI) of all sets of IMS service transport rules in theIMS Transport Policy with the details of the particular IMS-basedservice for initiation of a new call/session, modification of anexisting call/session, or transmission of a message. The details of theparticular IMS-based service for the initiated new call/session,modified existing call/session, or transmitted message may be includedin the contents or elements of the body (e.g., SDP) and/or header fields(e.g., a preferred ICSI such as in a Contact header field) of the SIPmethod that is to be sent by the UE for the new call/session that isinitiated, the existing call/session that is modified, or the messagethat is transmitted.

If one set of IMS service transport rules from the stored IMS TransportPolicy is matched to details of the particular IMS-based service for thenew call/session initiation, the existing call/session modification, orthe message transmissions, that set of IMS service transport rules isconsidered the selected set of IMS service transport rules. If two ormore sets of IMS service transport rules from the stored IMS TransportPolicy are matched to details of the particular IMS-based service forthe initiated new call/session, the modified existing call/session, orthe transmitted message, then one set of IMS service transport rules isselected. That is, one of the sets is considered the selected set of IMSservice transport rules in such case. The selection of the set of IMSservice transport rules may be based on one or more of a NetworkIdentity associated with the particular transport, the date or day, thetime, and/or a priority or order indicated in the matched sets of IMSservice transport rules.

If no sets of IMS service transport rules from the stored IMS TransportPolicy are matched to details of the particular IMS-based service forthe initiation of a new call/session, modification of an existingcall/session, or transmission of a message, then the UE may select a setof IMS service transport rules based on some other criteria, such as a“default” set of IMS service transport rules.

If at least one set of IMS service transport rules is selected and atleast one transport is available to the UE to transport IMS controlplane IP flows, and (optionally) if the UE has determined that thenetwork supports the provision of a transport policy, then severalconditions may apply. First, no transport may be allowed to transportIMS user plane IP flows. That is, all transports available to the UE maybe prohibited according to the selected IMS service transport rules. Insuch cases, the IMS-based service to be initiated by the UE may beeither known or not known by the UE to require user plane IP flows(e.g., voice call or video call).

If such information is known by the UE (e.g., by analysis of the SID),then the UE may prohibit the initiation of the IMS-based service. Thatis, the UE does not send the SIP method for the IMS-based service to thenetwork. If such information is unknown by the UE, then the UE mayprohibit the initiation of the IMS-based service or may allow theinitiation of the IMS-based service. That is, the UE may, but need not,send the SIP method for the IMS-based service to the network.

Alternatively, if at least one transport that is available to the UE isallowed (according to the selected IMS service transport rules) totransport IMS user plane IP flows, then the UE may allow the initiationof the IMS-based service. That is, the UE may send the SIP method forthe IMS-based service to the network.

If the transport policy is obtained using SIP signaling, then the UE maybe permitted to initiate the SIP registration and subscription to thepolicy mechanism to attempt to obtain the transport policy.

For all cases where the IMS-based service to be initiated or modified isallowed, then the UE may execute the procedure depicted in FIG. 3 anddescribed in the accompanying description.

When the UE creates one or both of dynamically created routing policiesfor the control plane and dynamically created routing policies for theuser plane, higher layers of the UE may inform lower layers of the UE tocreate the routing policies (e.g. ISRP, IARP, etc.) by using new ATcommands or enhanced existing AT commands.

If a new call/session fails or is prohibited from being established, orif an existing call/session is prohibited from being modified, or if amessage is prohibited from being sent due to IMS Transport Policyprohibiting the use of any available transport, then the UE may providean indication to the user of the UE informing the user of the failure orprohibition. For example, the UE may display a message on a screenassociated with the UE, may provide audible feedback using a speakerassociated with the UE, may vibrate, and/or may cause an LED or lampassociated with the UE to switch on, switch off, change color, blink,blink with a certain color, or blink at a certain rate.

As an alternative to the initiation or modification of an existingcall/session for a particular IMS-based service, other reasons ortriggers may cause the UE to apply IMS Transport Policy to ongoingcalls/sessions. For example, a timer in the device may expire or acertain time and/or a certain date may occur. Alternatively, UE mayreceive an indication by the user via an input mechanism associated withthe device, such as a physical or virtual keyboard; a physical orvirtual keypad; a physical button on the device; a voice, sound, ormicrophone input; and/or one or more sensors associated with the devicethat can detect movement and/or the direction of the device.Alternatively, using indications received as part of the RAN Rulesframework, the UE may receive an indication from the HPLMN or VPLMN tocommence steering or off-loading of data or traffic. That is, the UE mayreceive a trigger to off-load or steer data/traffic by one or moreindications in an information element (IE) received by the UE from anattached network in a radio broadcast channel (e.g., a SIB informationelement) and/or an IE in a received dedicated message (e.g., anRRCConnectionReconfiguration message or an ACTIVE SET UPDATE message).

In the case of a UE receiving an indication from the HPLMN or VPLMN,example standards text for 3GPP TS 36.300 is shown in FIG. 13.Alternative example standards text for 3GPP TS 36.300 in such a case isshown in FIG. 14. Other information elements and/or other messages maybe used by the UE to receive the indication from the HPLMN or VPLMN tocommence steering or off-loading of data or traffic.

The above may be implemented by a network element. A simplified networkelement is shown with regard to FIG. 15. In FIG. 15, network element3110 includes a processor 3120 and a communications subsystem 3130,where the processor 3120 and communications subsystem 3130 cooperate toperform the methods described above.

Further, the above may be implemented by a UE. An example of a UE isdescribed below with regard to FIG. 16. UE 3200 may comprise a two-waywireless communication device having voice and data communicationcapabilities. In some embodiments, voice communication capabilities areoptional. The UE 3200 generally has the capability to communicate withother computer systems on the Internet. Depending on the exactfunctionality provided, the UE 3200 may be referred to as a datamessaging device, a two-way pager, a wireless e-mail device, a cellulartelephone with data messaging capabilities, a wireless Internetappliance, a wireless device, a smart phone, a mobile device, or a datacommunication device, as examples.

Where the UE 3200 is enabled for two-way communication, it mayincorporate a communication subsystem 3211, including a receiver 3212and a transmitter 3214, as well as associated components such as one ormore antenna elements 3216 and 3218, local oscillators (LOs) 3213, and aprocessing module such as a digital signal processor (DSP) 3220. Theparticular design of the communication subsystem 3211 may be dependentupon the communication network in which the UE 3200 is intended tooperate.

Network access requirements may also vary depending upon the type ofnetwork 3219. In some networks, network access is associated with asubscriber or user of the UE 3200. The UE 3200 may require a removableuser identity module (RUIM) or a subscriber identity module (SIM) cardin order to operate on a network. The SIM/RUIM interface 3244 istypically similar to a card slot into which a SIM/RUIM card may beinserted. The SIM/RUIM card may have memory and may hold many keyconfigurations 3251 and other information 3253, such as identificationand subscriber-related information.

When required network registration or activation procedures have beencompleted, the UE 3200 may send and receive communication signals overthe network 3219. As illustrated, the network 3219 may comprise multiplebase stations communicating with the UE 3200.

Signals received by antenna 3216 through communication network 3219 areinput to receiver 3212, which may perform such common receiver functionsas signal amplification, frequency down conversion, filtering, channelselection, and the like. Analog to digital (A/D) conversion of areceived signal allows more complex communication functions, such asdemodulation and decoding to be performed in the DSP 3220. In a similarmanner, signals to be transmitted are processed, including modulationand encoding for example, by DSP 3220 and are input to transmitter 3214for digital to analog (D/A) conversion, frequency up conversion,filtering, amplification, and transmission over the communicationnetwork 3219 via antenna 3218. DSP 3220 not only processes communicationsignals but also provides for receiver and transmitter control. Forexample, the gains applied to communication signals in receiver 3212 andtransmitter 3214 may be adaptively controlled through automatic gaincontrol algorithms implemented in DSP 3220.

The UE 3200 generally includes a processor 3238 which controls theoverall operation of the device. Communication functions, including dataand voice communications, are performed through communication subsystem3211. Processor 3238 also interacts with further device subsystems suchas the display 3222, flash memory 3224, random access memory (RAM) 3226,auxiliary input/output (I/O) subsystems 3228, serial port 3230, one ormore keyboards or keypads 3232, speaker 3234, microphone 3236, othercommunication subsystem 3240 such as a short-range communicationssubsystem, and any other device subsystems generally designated as 3242.Serial port 3230 may include a USB port or other port currently known ordeveloped in the future.

Some of the illustrated subsystems perform communication-relatedfunctions, whereas other subsystems may provide “resident” or on-devicefunctions. Notably, some subsystems, such as keyboard 3232 and display3222, for example, may be used for both communication-related functions,such as entering a text message for transmission over a communicationnetwork, and device-resident functions, such as a calculator or tasklist.

Operating system software used by the processor 3238 may be stored in apersistent store such as flash memory 3224, which may instead be aread-only memory (ROM) or similar storage element (not shown). Theoperating system, specific device applications, or parts thereof, may betemporarily loaded into a volatile memory such as RAM 3226. Receivedcommunication signals may also be stored in RAM 3226.

As shown, flash memory 3224 may be segregated into different areas forboth computer programs 3258 and program data storage 3250, 3252, 3254and 3256. These different storage types indicate that each program mayallocate a portion of flash memory 3224 for their own data storagerequirements. Processor 3238, in addition to its operating systemfunctions, may enable execution of software applications on the UE 3200.A predetermined set of applications that control basic operations,including at least data and voice communication applications forexample, may typically be installed on the UE 3200 during manufacturing.Other applications may be installed subsequently or dynamically.

Applications and software may be stored on any computer-readable storagemedium. The computer-readable storage medium may be tangible or in atransitory/non-transitory medium such as optical (e.g., CD, DVD, etc.),magnetic (e.g., tape), or other memory currently known or developed inthe future.

One software application may be a personal information manager (PIM)application having the ability to organize and manage data itemsrelating to the user of the UE 3200 such as, but not limited to, e-mail,calendar events, voice mails, appointments, and task items. One or morememory stores may be available on the UE 3200 to facilitate storage ofPIM data items. Such a PIM application may have the ability to send andreceive data items via the wireless network 3219. Further applicationsmay also be loaded onto the UE 3200 through the network 3219, anauxiliary I/O subsystem 3228, serial port 3230, short-rangecommunications subsystem 3240, or any other suitable subsystem 3242, andinstalled by a user in the RAM 3226 or a non-volatile store (not shown)for execution by the processor 3238. Such flexibility in applicationinstallation may increase the functionality of the UE 3200 and mayprovide enhanced on-device functions, communication-related functions,or both. For example, secure communication applications may enableelectronic commerce functions and other such financial transactions tobe performed using the UE 3200.

In a data communication mode, a received signal such as a text messageor web page download may be processed by the communication subsystem3211 and input to the processor 3238, which may further process thereceived signal for output to the display 3222, or alternatively to anauxiliary I/O device 3228.

A user of the UE 3200 may also compose data items, such as emailmessages for example, using the keyboard 3232, which may be a completealphanumeric keyboard or telephone-type keypad, among others, inconjunction with the display 3222 and possibly an auxiliary I/O device3228. Such composed items may then be transmitted over a communicationnetwork through the communication subsystem 3211.

For voice communications, overall operation of the UE 3200 is similar,except that received signals may typically be output to a speaker 3234and signals for transmission may be generated by a microphone 3236.Alternative voice or audio I/O subsystems, such as a voice messagerecording subsystem, may also be implemented on the UE 3200. Althoughvoice or audio signal output may be accomplished primarily through thespeaker 3234, display 3222 may also be used to provide an indication ofthe identity of a calling party, the duration of a voice call, or othervoice call-related information, for example.

Serial port 3230 may be implemented in a personal digital assistant(PDA)-type device for which synchronization with a user's desktopcomputer (not shown) may be desirable, but such a port is an optionaldevice component. Such a port 3230 may enable a user to set preferencesthrough an external device or software application and may extend thecapabilities of the UE 3200 by providing for information or softwaredownloads to the UE 3200 other than through a wireless communicationnetwork. The alternate download path may, for example, be used to loadan encryption key onto the UE 3200 through a direct and thus reliableand trusted connection to thereby enable secure device communication.Serial port 3230 may further be used to connect the device to a computerto act as a modem.

Other communications subsystems 3240, such as a short-rangecommunications subsystem, are further optional components which mayprovide for communication between the UE 3200 and different systems ordevices, which need not necessarily be similar devices. For example, thesubsystem 3240 may include an infrared device and associated circuitsand components or a Bluetooth™ communication module to provide forcommunication with similarly enabled systems and devices. Subsystem 3240may further include non-cellular communications such as WiFi, WiMAX,near field communication (NFC), and/or radio frequency identification(RFID). The other communications element 3240 may also be used tocommunicate with auxiliary devices such as tablet displays, keyboards orprojectors.

The UE and other components described above might include a processingcomponent that is capable of executing instructions related to theactions described above. FIG. 17 illustrates an example of a system 3300that includes a processing component 3310 suitable for implementing oneor more embodiments disclosed herein. In addition to the processor 3310(which may be referred to as a central processor unit or CPU), thesystem 3300 might include network connectivity devices 3320, randomaccess memory (RAM) 3330, read only memory (ROM) 3340, secondary storage3350, and input/output (I/O) devices 3360. These components mightcommunicate with one another via a bus 3370. In some cases, some ofthese components may not be present or may be combined in variouscombinations with one another or with other components not shown. Thesecomponents might be located in a single physical entity or in more thanone physical entity. Any actions described herein as being taken by theprocessor 3310 might be taken by the processor 3310 alone or by theprocessor 3310 in conjunction with one or more components shown or notshown in the drawing, such as a digital signal processor (DSP) 3380.Although the DSP 3380 is shown as a separate component, the DSP 3380might be incorporated into the processor 3310.

The processor 3310 executes instructions, codes, computer programs, orscripts that it might access from the network connectivity devices 3320,RAM 3330, ROM 3340, or secondary storage 3350 (which might includevarious disk-based systems such as hard disk, floppy disk, or opticaldisk). While only one CPU 3310 is shown, multiple processors may bepresent. Thus, while instructions may be discussed as being executed bya processor, the instructions may be executed simultaneously, serially,or otherwise by one or multiple processors. The processor 3310 may beimplemented as one or more CPU chips.

The network connectivity devices 3320 may take the form of modems, modembanks, Ethernet devices, universal serial bus (USB) interface devices,serial interfaces, token ring devices, fiber distributed data interface(FDDI) devices, wireless local area network (WLAN) devices, radiotransceiver devices such as code division multiple access (CDMA)devices, global system for mobile communications (GSM) radio transceiverdevices, universal mobile telecommunications system (UMTS) radiotransceiver devices, long term evolution (LTE) radio transceiverdevices, worldwide interoperability for microwave access (WiMAX)devices, and/or other well-known devices for connecting to networks.These network connectivity devices 3320 may enable the processor 3310 tocommunicate with the Internet or one or more telecommunications networksor other networks from which the processor 3310 might receiveinformation or to which the processor 3310 might output information. Thenetwork connectivity devices 3320 might also include one or moretransceiver components 3325 capable of transmitting and/or receivingdata wirelessly.

The RAM 3330 might be used to store volatile data and perhaps to storeinstructions that are executed by the processor 3310. The ROM 3340 is anon-volatile memory device that typically has a smaller memory capacitythan the memory capacity of the secondary storage 3350. ROM 3340 mightbe used to store instructions and perhaps data that are read duringexecution of the instructions. Access to both RAM 3330 and ROM 3340 istypically faster than to secondary storage 3350. The secondary storage3350 is typically comprised of one or more disk drives or tape drivesand might be used for non-volatile storage of data or as an over-flowdata storage device if RAM 3330 is not large enough to hold all workingdata. Secondary storage 3350 may be used to store programs that areloaded into RAM 3330 when such programs are selected for execution.

The I/O devices 3360 may include liquid crystal displays (LCDs), touchscreen displays, keyboards, keypads, switches, dials, mice, track balls,voice recognizers, card readers, paper tape readers, printers, videomonitors, or other well-known input/output devices. Also, thetransceiver 3325 might be considered to be a component of the I/Odevices 3360 instead of or in addition to being a component of thenetwork connectivity devices 3320.

The following are incorporated herein by reference for all purposes:3GPP TS 27.007, 3GPP TS 22.278, 3GPP TS 23.402, 3GPP TS 24.312, 3GPP TS36.300, 3GPP TS 36.304, 3GPP TS 36.331, 3GPP TS 24.237, 3GPP TS 24.216,3GPP TS 24.229, 3GPP TS 23.401, 3GPP TS 24.604, 3GPP TS 24.167, 3GPP TS23.228, 3GPP TS 24.341, 3GPP TS 31.102, 3GPP TS 31.103, 3GPP TS 24.008,3GPP TS 24.301, 3GPP TS 23.203, 3GPP TS 23.060, IETF RFC 3260, IETF RFC4566, IETF RFC 3840, IETF RFC 6795, IETF Draftdraft-mccann-session-policy-framework-using-eap, GSMA PRD IR.92, andGSMA PRD IR.94.

In an embodiment, a method on a UE is provided. The method comprisescreating, by the UE, at least one routing policy based on at least oneset of IMS service transport rules; communicating, by an upper protocollayer of the UE, information regarding the at least one routing policyto a lower protocol layer of the UE; and transmitting, by the lowerprotocol layer of the UE, data to an IMS network using an accesstechnology or PDN Connection, according to the at least one routingpolicy.

In another embodiment, a UE is provided. The UE comprises a memorycontaining instructions and a processor coupled to the memory. Theprocessor is configured to execute the instructions such that the UEcreates at least one routing policy based on at least one set of IMSservice transport rules, and such that an upper protocol layer of the UEcommunicates information regarding the at least one routing policy to alower protocol layer of the UE, and such that the lower protocol layerof the UE transmits data to an IMS network using an access technology orPDN Connection, according to the at least one routing policy.

In another embodiment, a computer-readable medium is provided. Thecomputer-readable medium contains instructions that, when executed by aprocessor cause a UE to create at least one routing policy based on atleast one set of IMS service transport rules, and cause an upperprotocol layer of the UE to communicate information regarding the atleast one routing policy to a lower protocol layer of the UE, and causethe lower protocol layer of the UE to transmit data to an IMS networkusing an access technology or PDN Connection, according to the at leastone routing policy.

While several embodiments have been provided in the present disclosure,it should be understood that the disclosed systems and methods may beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

Also, techniques, systems, subsystems and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component, whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and could be made without departing from the spirit and scopedisclosed herein.

What is claimed is:
 1. A method on a user equipment (UE), the methodcomprising: creating, by the UE, at least one routing policy based on atleast one set of Internet Protocol (IP) Multimedia Subsystem (IMS)service transport rules; transmitting, by the UE, data to an IMS networkusing an access technology or Packet Data Network (PDN) Connection,wherein the access technology or PDN Connection is selected according tothe at least one routing policy; and when the at least one set of IMSservice transport rules contains an indication regarding a “Data Off”mode for the UE, indicating whether one or more IMS services are allowedor prohibited for one or more transports identified in the IMS servicetransport rules.
 2. The method of claim 1, wherein the at least onerouting policy includes at least one routing policy for a control planeand/or a user plane.
 3. The method of claim 1, wherein the at least onerouting policy includes at least one policy for a user plane establishedbetween the UE and a network responsive to determining that there isuser plane data to transport after a Session Initiation Protocol (SIP)session is established.
 4. The method of claim 3, wherein the UE createsthe at least one policy to ensure IP data flows over the user plane areuniquely identified.
 5. The method of claim 3, wherein the UE createsthe at least one policy based on Service Description Protocol (SDP)information related to the SIP session, wherein the SDP informationincludes an indication of one or more ports to be used for transportingmedia on the user plane of the SIP session.
 6. The method of claim 1,further comprising communicating, by an upper protocol layer of the UE,information regarding the at least one routing policy to a lowerprotocol layer of the UE, wherein the upper protocol layer communicatesthe at least one routing policy to the lower protocol layer using new orenhanced ATtention (AT) commands.
 7. The method of claim 1, whereincreating the at least one routing policy further comprises identifyingan IMS service based on one or more of: an IMS Communication ServiceIdentifier (ICSI); an IMS Application Reference Identifier (IARI); afeature tag; a media feature tag; a component of a Service DescriptionProtocol (SDP) description; a Session Initiation Protocol (SIP) method;a SIP response; or a Mapping Code.
 8. The method of claim 1, whereincreating the at least one routing policy further comprises identifying,based on an IMS transport policy, at least one of: an allowed RadioAccess Technology (RAT); a barred RAT; an allowed Access Point Name(APN); or a barred APN.
 9. The method of claim 8, wherein, when morethan one allowed RAT, barred RAT, allowed APN, or barred APN isidentified, an indication of a preference of the more than one allowedRAT, barred RAT, allowed APN, or barred APN is included in the at leastone routing policy.
 10. The method of claim 1, wherein the at least oneset of IMS service transport rules contains an indication indicatingwhether the UE is allowed or prohibited to use one or more transportsfor one or more IMS services identified in the IMS service transportrules.
 11. A user equipment (UE) comprising: a memory containinginstructions; and a processor coupled to the memory and configured toexecute the instructions such that the UE creates at least one routingpolicy based on at least one set of Internet Protocol (IP) MultimediaSubsystem (IMS) service transport rules, and such that the UE transmitsdata to an IMS network using an access technology or Packet Data Network(PDN) Connection, wherein the access technology or PDN Connection isselected according to the at least one routing policy, wherein, when theat least one set of IMS service transport rules contains an indicationregarding a “Data Off” mode for the UE, an indication is providedregarding whether one or more IMS services are allowed or prohibited forone or more transports identified in the IMS service transport rules.12. The UE of claim 11, wherein the at least one routing policy includesat least one policy for a control plane and/or a user plane.
 13. The UEof claim 11, wherein the at least one routing policy includes at leastone policy for a user plane established between the UE and a networkresponsive to determining that there is user plane data to transportafter a Session Initiation Protocol (SIP) session is established. 14.The UE of claim 13, wherein the UE creates the at least one policy toensure IP data flows over the user plane are uniquely identified. 15.The UE of claim 13, wherein the UE creates the at least one policy basedon Service Description Protocol (SDP) information related to the SIPsession, wherein the SDP information includes an indication of one ormore ports to be used for transporting media on the user plane of theSIP session.
 16. The UE of claim 11, wherein an upper protocol layer ofthe UE communicates the at least one routing policy to a lower protocollayer of the UE using new or enhanced ATtention (AT) commands.
 17. TheUE of claim 11, wherein the creation of the at least one routing policyfurther comprises identifying an IMS service based on one or more of: anIMS Communication Service Identifier (ICSI); an IMS ApplicationReference Identifier (IARI); a feature tag; a media feature tag; acomponent of a Service Description Protocol (SDP) description; a SessionInitiation Protocol (SIP) method; a SIP response; or a Mapping Code. 18.The UE of claim 11, wherein the creation of the at least one routingpolicy further comprises identifying, based on an IMS transport policy,at least one of: an allowed Radio Access Technology (RAT); a barred RAT;an allowed Access Point Name (APN); or a barred APN.
 19. The UE of claim18, wherein, when more than one allowed RAT, barred RAT, allowed APN, orbarred APN is identified, an indication of a preference of the more thanone allowed RAT, barred RAT, allowed APN, or barred APN is included inthe at least one routing policy.
 20. The UE of claim 11, wherein the atleast one set of IMS service transport rules contains an indication ofwhether the UE allowed or prohibited to use one or more transports forone or more IMS services identified in the IMS service transport rules.21. A non-transitory computer-readable medium containing instructionsexecutable by a processor such that when executed, cause the processorto implement a method on a user equipment (UE), the method comprising:creating, by the UE, at least one routing policy based on at least oneset of Internet Protocol (IP) Multimedia Subsystem (IMS) servicetransport rules; transmitting, by the UE, data to an IMS network usingan access technology or Packet Data Network (PDN) Connection, whereinthe access technology or PDN Connection is selected according to the atleast one routing policy; when the at least one set of IMS servicetransport rules contains an indication regarding a “Data Off” mode forthe UE, indicating whether one or more IMS services are allowed orprohibited for one or more transports identified in the IMS servicetransport rules.
 22. The non-transitory computer-readable medium ofclaim 21, wherein the at least one routing policy includes at least onepolicy for a control plane and/or a user plane.
 23. The non-transitorycomputer-readable medium of claim 21, wherein the at least one routingpolicy includes at least one policy for a user plane established betweenthe UE and a network responsive to determining that there is user planedata to transport after a Session Initiation Protocol (SIP) session isestablished.
 24. The non-transitory computer-readable medium of claim23, wherein the UE creates the at least one policy to ensure IP dataflows over the user plane are uniquely identified.
 25. Thenon-transitory computer-readable medium of claim 23, wherein the UEcreates the at least one policy based on Service Description Protocol(SDP) information related to the SIP session, wherein the SDPinformation includes an indication of one or more ports to be used fortransporting media on the user plane of the SIP session.
 26. Thenon-transitory computer-readable medium of claim 21, wherein an upperprotocol layer of the UE communicates the at least one routing policy toa lower protocol layer of the UE using new or enhanced ATtention (AT)commands.
 27. The non-transitory computer-readable medium of claim 21,wherein the creation of the at least one routing policy furthercomprises identifying an IMS service based on one or more of: an IMSCommunication Service Identifier (ICSI); an IMS Application ReferenceIdentifier (IARI); a feature tag; a media feature tag; a component of aService Description Protocol (SDP) description; a Session InitiationProtocol (SIP) method; a SIP response; or a Mapping Code.
 28. Thenon-transitory computer-readable medium of claim 21, wherein thecreation of the at least one routing policy further comprisesidentifying, based on an IMS transport policy, at least one of: anallowed Radio Access Technology (RAT); a barred RAT; an allowed AccessPoint Name (APN); or a barred APN.
 29. The non-transitorycomputer-readable medium of claim 28, wherein, when more than oneallowed RAT, barred RAT, allowed APN, or barred APN is identified, anindication of a preference of the more than one allowed RAT, barred RAT,allowed APN, or barred APN is included in the at least one routingpolicy.
 30. The non-transitory computer-readable medium of claim 21,wherein the at least one set of IMS service transport rules contains anindication of whether the UE is allowed or prohibited to use one or moretransports for one or more IMS services identified in the IMS servicetransport rules.